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2 (U) Requirements 

2.1 (U) Overview 

1. (C//SI//REL FVEY) This document has been coordinated with NSA/CES. 

2. (U//FOUO) Cryptographic jargon is utilized throughout this document. This jargon has precise and 
subtle meaning and should not be interpreted without careful understanding of the subject matter. 
Suggested reading includes Practical Cryptography by Schneier and Ferguson, RFCs 4251 and 4253, 
RFCs 5246 and 5430, and Handbook of Applied Cryptography by Menezes, van Oorschot, and 
Vanstone. Special mention must be made of NIST SP 800-57-1 (draft May 2011 or later), which is a 
very thorough explanation of cryptosystem design details, ands its excellent discussion on security 
strength (generally half the shortest key length) and their expected lifetimes in Section 5.6. Further 
references are noted in the commentary section. 

3. (U//FOUO) These requirements bear intentional similarity to the National Security Agency's Suite B 
of Cryptographic Algorithms as well as industry best practice. 

4. (C//NF) These requirements are intended to ensure a satisfactory minimum level of security for 
tools used to advance the CIA's intelligence collection activities. Because not every idea can be 
foreseen authors with particularly novel or creative ideas are encouraged to contact the IOC 
Operational Cryptography Review Board (OCRB) for discussion if it appears the idea cannot be made 
to comply with these requirements. 

5. (C//NF) A tool satisfying all requirements of this document may be described as "Compliant with the 
Network Operations Division Cryptographic Requirements version X" where X is the version number 
listed on the title page of this document. 

6. (C//NF) This document intentionally refers to non-embedded device software only. 

2.2 (U) Terminology 

1. (U) MUST - This word, or the term "SFIALL", means that the definition is an unconditional 
requirement of this specification. 

2. (U) MUST NOT - This phrase, or the phrase "SFIALL NOT", means that the definition is an 
unconditional prohibition of the specification. 

3. (C//NF) SHOULD - This word, or the adjective "RECOMMENDED", means that there may exist valid 
reasons in particular circumstances to ignore a particular item, but the full implications must be 
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understood and carefully weighed before choosing a different course. The recommendations of this 
document outline options for increased security above and beyond the bare essential. The choices 
made in these items will be prime criteria for evaluation against competing solutions. Given CIA's 
hostile operating environment it is expected that more secure solutions will generally be preferred. 

4. (C//NF) SHOULD NOT -This phrase, or the phrase "NOT RECOMMENDED" mean that there may 
exist valid reasons in particular circumstances when the particular behavior is acceptable or even 
useful, but the full implications should be understood and the case carefully weighed before 
implementing any behavior described with this label. The recommendations of this document 
outline options for increased security above and beyond the bare essential. The choices made in 
these items will be prime criteria for evaluation against competing solutions. Given CIA's hostile 
operating environment it is expected that more secure solutions will generally be preferred. 

5. (U) MAY - This word, or the adjective "OPTIONAL", means that an item is truly optional. 

6. (C//NF) TARGET - This word is used in reference to a deployed tool or implant executing on an 
untrusted or hostile device and communicating over an untrusted or hostile network. This word may 
also be used to refer to the untrusted or hostile device itself. CIA personnel will not have physical 
access to or control of items on the target. 

7. (S//NF) SERVER - This word is used in reference to CIA controlled infrastructure or personnel. This 
word does not refer to intermediate nodes used for the purposes of redirection. CIA control does 
not indicate the absence of hostile implantation or exploitation; most server components will be 
exposed to hostile network connections and exploitation attempts and may be executing on 
hardware not under immediate CIA supervision. Designs incorporating defense in depth are 
recommended. 

8. (S//NF) TRANSPORT - This word means the overt communication protocol being exercised between 
the target and the server as a cover for action. For example, HTTPS, SMTP, IMAP, Jabber, Windows 
Error Reporting, Skype. 

9. (S//NF) TRANSPORT ENCRYPTION - This phrase refers to the native encryption available for a 
transport where the use of that encryption with the transport protocol would be considered 
innocuous by the average observer (e.g., SSL/TLS for HTTPS, Encrypted Skype chat, SSL/TLS for 
secure Jabber, Encrypted RDP). This explicitly does not refer to any inner cryptostream compliant 
with the encryption suites as defined below. 

10. (C//NF) BLENDING - This word means the actions taken by the transport to assure passive or active 
observers of the benign nature of the communication, concealing its true purpose. 

11. (C//NF) TAKE - This word refers to all data collected from a target in the course of a CIA clandestine 
operation. All take is considered raw intelligence until assessed otherwise and maximum care must 
be taken to preserve it. 
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2.3 (U) Changelog 

1. (U) Version 1.0 to 1.1 

a. (C//SI//REL FVEY) Coordinated with NSA/CES. 

b. (U) 2.1: Created Overview section from bullets originally present in Terminology and section 
2.4. 

c. (C//NF) 2.2.11: Added "TAKE" to Terminology 

d. (C//NF) 2.4.15: Added PKCS #5 as a synonym for ANSI X.923 symmetric padding. 

e. (S//NF) 3.7, 4.7, 5.8: No longer discourage use of CBC mode. Though slightly inferior to other 
modes of operation it is widely available in standard APIs and encourages their use. 

f. (TS//SI) 5.9: Added additional information about proper use of RC4. 

g. (U//FOUO) Added Portion marking. 

h. (S//NF) 2.2.6: Clarify the definition of "TARGET" to include interchangeable use of an 
implant and the computer hosting the implant. 

i. (C//NF) 2.4.19: Clarify that any use of transport encryption is layered over the encryption 
specified in this document. 

j. (S//NF) 2.1.6: Clarify this document does not refer to embedded devices or hardware 
implants. 

k. (U//FOUO) 8.i: Clarify some reasons asymmetric cryptography is so pervasive in this 
document. 

l. (U//FOUO) 2.4.16: Prohibit the use of PKCS #lvl.5 asymmetric padding. 

m. (U//FOUO) 3.1, 4.1, 5.1: Clarify that Diffie-Flellman and RSA must have larger keys than 
ECDH. 

n. (U//FOUO) 3.1, 4.1, 5.1: Clarify that Diffie-Flellman alone does not provide perfect forward 
secrecy. 

o. (U//FOUO) 2.1.7: Added bullet clarifying the nature of the classification of this document 
and acceptable means to lower the classification. 


2.4 (C//NF) Tools with initial delivery 1 January 2012 or later 
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1. (S//NF) All tools utilizing network communication must implement either the Long-lived, Short-lived, 
or Collection Encryption Suite of cryptographic algorithms as defined below. A tool's author must 
implement the appropriate suite for the tool's Concept of Operation (CONOP). 1 

2. (S//NF) All tools should implement the Tool State Encryption Suite in reference to configurable state 
(e.g., callback addresses, intervals, subsequent persistent cryptographic keys). Tool authors may 
extend the implementation of the Tool State Encryption Suite to tool components (e.g., code blocks, 
packaged components within an installer) but must carefully consider and evaluate the impact on 
PSP performance. 

3. (S//NF) All cached or otherwise stored take which has not yet been transferred to server and is not 
stored in RAM should be protected using the Collection Encryption Suite. 

4. (S//NF) Communications involving only file exchange (e.g., an automated implant collecting tasking 
or submitting tasking results) must encrypt the exchanged file using the Collection Encryption Suite. 
This encryption must be separate from and additional to any transport encryption. Such 
communications may incorporate either the Long-lived or Short-lived Suites. 

5. (S//NF) All tools must utilize Operating System (OS) provided cryptographic primitives where 
available (e.g., Microsoft CryptoAPI-NG, OpenSSL, PolarSSL, GnuTLS, etc). Note the guidance in the 
relevant encryption suites regarding suitable Certificate Authorities (CAs) for each phase of 
communication. Deviations must be justified and accepted by the OCRB." 

6. (S//NF) All tools must utilize OS provided cryptographically secure sources of entropy (e.g., 
/dev/random on *nix, Microsoft CryptoAPI, etc) and should be a source compliant with NIST SP 800- 
90. If a non-800-90 mechanism is used, the output from the source of entropy must be hashed with 
SFIA-256 prior to use. Deviations from this must be justified and accepted by the OCRB. 1 " 

7. (S//NF) All message digests must be performed using SFIA-256, SFIA-384, or SFIA-512 without 
truncation. HMACs must be performed using HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 
without truncation. IV Digests and FIMACs must be computed over the ciphertext (to include 
Initialization Vectors) of each message vice the plaintext/ 

8. (U) Asymmetric cryptography must not be used directly for bulk encryption. It must only be used to 
negotiate or exchange secrets used for symmetric encryption and for digital signatures and their 
verification/ 1 

9. (S//NF) Communication adhering to these requirements involves multiple cryptographic keys, 
whether used for encryption, authentication, or integrity checking. All entropy used for key material 
(including components of key exchange) must be generated using a source of randomness as 
defined in 6 above. Keys should be generated independently where possible but may be derived 
from an exchanged secret using Key Derivation Functions (KDFs) approved by NIST SP 800-108 
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(October 2009) and NIST SP 800-56C (second draft July 2011) or later revisions. VM If such a KDF is 
chosen then the exchanged secret must have a length equal to sum of the lengths for all needed key 
material (e.g., 512 bits if two 256 bit keys are required). Vl " The guidance regarding hashing algorithm 
selection in 7 above applies to the hashing algorithms chosen for use with the KDF. 

10. (S//NF) Messages should be compressed prior to encryption. IX Compression must be performed 
using appropriate domain-specific compression (e.g., MP3 for audio, BZIP2, GZIP, ZUB, or raw 
DEFLATE for arbitrary data)/ Compression should be performed using OS provided APIs/ 1 Authority 
to determine whether a compression routine is considered appropriate for a domain rests with the 
OCRB. 

11. (S//NF) For pseudo One Time Pad ciphers and block modes (i.e., RC4, CTR, GCM), all communication 
from target to server must use distinct encryption keys from those used for server to target/" 

12. (S//NF) Tools should perform key exchange exactly once per connection. Many algorithms have 
weaknesses during key exchange and the volume of data expected during a given connection does 
not meet the threshold where a re-key is required/" 1 To reiterate, re-keying is not recommended. 

13. (S//NF) To guard against replay attacks every message sent must employ a nonce scheme. Nonces 
should take the form of monotonic message numbers and, if so, must track message numbers from 
each party separately. Alternatively, nonce schemes may use a timestamp easily converted to a full 
UTC date and time but due to the difficulty in ensuring close time synchronization when messages 
are frequent, timestamps are not recommended. Nonce values must not be repeated for the same 
encryption key and authentication key combination. 

14. (S//NF) For CBC mode all Initialization Vectors (IVs) must be strong pseudorandomly generated, 
randomly generated as in 6 above, or generated using a KDF as permitted in 9 above/ lv For CTR and 
GCM mode, all IVs should start from zero and should use strong pseudorandom or random fixed 
field prefix padding to bring the counter value up to the minimum length.” All IVs must have a 
minimum length of one block of the chosen cipher.™ IVs must not be reused with the same 
encryption key.™" 

15. (S//NF) Padding for symmetric encryption, when required by the chosen cipher and mode, must be 
performed using either the PKCS #7 or ANSI X.923/PKCS #5 padding techniques.™ 1 " Padding must be 
applied after any compression but before any encryption. 

16. (S//NF) Padding for asymmetric encryption, when required, must not be performed using the PKCS 
#lvl.5 padding scheme™. OAEP padding is recommended. 

17. (C//NF) Proper key management must be carefully considered by tool authors to ensure that each 
deployed tool utilizes unique persistent keys (including unique server keys where appropriate). 
Authors must submit a key management plan outlining the mechanisms used to ensure uniqueness 
properties, proper usage, and archiving of all keys on a classified CIA network. 
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18. (C//NF) Tool authors must submit a cryptographic design document for approval to the OCRB. This 
document must contain sufficient information regarding the tools use and handling of the concepts 
discussed in these requirements to convince them that the design is secure. Specifically, this 
document must discuss key management (authors may reference their key management plan), IV 
selection, algorithm selection, message format (as it pertains to the cryptographic details), 
frequency of messages, error/failure handling, authentication, key exchange, integrity assurances, 
and similar details. Authors should expect that this design will be reviewed by other entities within 
the US Government (e.g., the NSA) while respecting Proprietary Information controls. Submission of 
this document early in the development cycle is recommended. A cryptographic design approval is 
valid for a single tool and remains valid until and unless authors undertake substantive changes in 
the use of cryptography or until the approval is revoked. 

19. (S//NF) These cryptographic suites are intended to protect the innermost layer of communication. It 
is expected and encouraged that transport protocol standards will additionally encrypt traffic 
exchanged via that transport as appropriate (e.g., FITTP over TCP port 80 should not be overtly 
encrypted but FITTPS over TCP port 443 should be). Any transport layer encryption must be layered 
over the cryptography discussed in this document. Because this outer layer may be decrypted by an 
attacker (e.g., SSL Man-in-the-Middle) any transport encryption must be used for traffic blending 
only and not for secrecy. xx 

20. (C//NF) The IOC Operational Cryptography Review Board (OCRB) must approve all deviations from 
these requirements. 


2.5 (C//NF) Tools with initial delivery prior to 1 January 2012 

1. (U//FOUO) Existing tools must implement all requirements for new tools as above. 

2. (C//NF) Optionally, existing tools may implement the Weak Suite instead of the Long-lived or Short- 
lived Suite of cryptographic algorithms as defined below. Tools which utilize the Weak Suite should 
plan to become compliant with either the Long-lived or Short-lived Suites. 

3. (U//FOUO) Approval of cryptographic design and key management plan is recommended but not 
mandatory. 
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3 (C//NF) The Long-lived Suite for Network Communication 


(S//NF) The Long-lived Suite of algorithms is intended for use with tools residing on a target or 
redirector for longer than one working day but may be used by tools with shorter expected lifetimes. In 
general the structure of the Long-lived Suite is similar to that of a TLS 1.2 handshake with client 
authentication, specifically in the use of asymmetric cryptography to provide authentication and key 
exchange followed by communication utilizing symmetric cryptographic primitives together with the 
exchanged secrets to provide confidentiality and integrity. The inclusion of TLS 1.2 in this suite does not 
imply that a protocol adhering to this suite may be described as "SSL" or "HTTPS". 

1. (S//NF) Key exchange must be performed using Diffie-Hellman, Elliptic Curve Diffie-Hellman, or RSA. 
For Elliptic Curve Diffie-Hellman the prime moduli utilized must be at least 256 bits. For Diffie- 
Hellman and RSA the primes utilized must be at least 2048 bits. The use of Diffie-Hellman or Elliptic 
Curve Diffie-Hellman is recommended to allow for perfect forward secrecy. 

2. (S//NF) Authentication must be performed using TLS 1.2, Elliptic Curve DSA, DSA, or RSA. 
Asymmetric keys must be at least 2048 bits (256 bits for elliptic curve prime moduli). 

3. (S//NF) Authentication via TLS 1.2 must include the use of certificates by both parties. 

4. (S//NF) Authentication via TLS 1.2 must validate that the certificate utilized by both parties match 
preshared certificates or a preshared CA. Should validation of either party fail, the other should 
terminate the connection but the termination decision may rest with the server component alone. 
Certificate validation must not be performed against any standard SSL root CAs. Note that this 
guidance refers to the inner cryptostream which may optionally be masked by HTTPS (or some other 
outer transport protocol), this does not refer to the certificates or encryption used by the outer 
blending channel. 

5. (S//NF) Tools must support the use of unique certificates and CAs for network authentication for 
each deployment or group of deployments (e.g., through Server Name Identification (SNI) extension 
for TLS). 

6. (S//NF) Integrity must be provided using HMAC with a key size of at least 256 bits. 

7. (S//NF) Confidentiality must be provided by AES with a minimum key size of 256 bits. The cipher 
must be operated in Galois/Counter Mode (GCM), Counter Mode (CTR), or Cipher Block Chaining 
Mode (CBC). 
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4 (C//NF) The Short-lived Suite for Network Communication 


(S//NF) The Short-lived Suite of algorithms is intended for use with tools residing on a target or 

redirector for less than one working day. Asymmetric cryptography is utilized to a lesser degree by the 

Short-lived Suite because the CONOP for the suite implies a far greater control of the tool by an 

operator and a lower risk of exposure to hostile actors. 

1. (S//NF) Key exchange must be performed using Diffie-Flellman, Elliptic Curve Diffie-Flellman, or RSA. 
For Elliptic Curve Diffie-Flellman the prime moduli utilized must be at least 256 bits. For Diffie- 
Flellman and RSA the primes utilized must be at least 2048 bits. The use of Diffie-Flellman or Elliptic 
Curve Diffie-Flellman is recommended to allow for perfect forward secrecy. 

2. (S//NF) Authentication must be provided using FIMAC, asymmetric cryptography, or by operating 
the chosen block cipher in Gaolis/Counter Mode (GCM). 

3. (S//NF) Authentication using FIMAC must use a key size of at least 256 bits. The key must be 
preshared and must not be reused for any other deployment. 

4. (S//NF) Authentication using asymmetric cryptography must be provided using TLS 1.2, Elliptic Curve 
DSA, DSA, or RSA using asymmetric keys of at least 2048 bits (256 bits for elliptic curve prime 
moduli). All authentication based on certificates and CAs must follow the requirements concerning 
certificates and CAs described in the Long-lived Suite paragraphs 4, and 5. 

5. (S//NF) Integrity must be provided using FIMAC with a key size of at least 256 bits. 

6. (S//NF) Authentication and Integrity FIMACs may be one and the same if FIMAC is used for 
authentication. 

7. (S//NF) Confidentiality must be provided by AES with a minimum key size of 256 bits. The cipher 
must be operated in Galois/Counter Mode (GCM), Counter Mode (CTR), or Cipher Block Chaining 
Mode (CBC). 
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5 (C//NF) The Weak Suite for Network Communication 

(S//NF) The Weak Suite is intended as a transition suite and must not be used for new tools. As 
the name implies, it provides reduced security compared to the other suites. Tools utilizing this suite 
should plan to transition to either the Long-lived or Short-lived Suites to facilitate deliveries once the 
Weak Suite has been retired. The Weak Suite shall be retired on 31 December 2013 and shall not be 
used for deliveries after that time. This date complies with NIST Special Publication 800-131A regarding 
protection of unclassified data for US Government systems. 

1. (S//NF) Key exchange must be performed using Diffie-Flellman, Elliptic Curve Diffie-Flellman, or RSA. 
For Elliptic Curve Diffie-Flellman the prime moduli utilized must be at least 128 bits. For Diffie- 
Flellman and RSA the primes utilized must be at least 1024 bits. The use of Diffie-Flellman or Elliptic 
Curve Diffie-Flellman is recommended to allow for perfect forward secrecy. 

2. (S//NF) Authentication must be provided using FIMAC, asymmetric cryptography, or by operating 
the chosen block cipher in Gaolis/Counter Mode (GCM). 

3. (S//NF) Authentication using FIMAC (which may include FIMAC-SFIA1) must use a key size of at least 
128 bits. The key must be preshared and must not be reused for any other deployment. 

4. (S//NF) Authentication using asymmetric cryptography must be provided using TLS 1.2, Elliptic Curve 
DSA, DSA, or RSA with asymmetric keys of at least 1024 bits (128 bits for elliptic curve prime 
moduli). All certificate and CA handling instructions and requirements from the Long-lived Suite 
must also be applied. 

5. (S//NF) Authentication using GCM mode must use a tag length of 128. The author must carefully 
consider NIST SP 800-38D (November 2007), especially the peculiarities described in Appendixes A 
and B. 

6. (S//NF) Integrity must be provided using FIMAC (which may include FIMAC-SFIA1) with a key size of 
at least 128 bits. Alternatively, integrity may be provided by using Elliptic Curve DSA, DSA, or RSA 
signatures on message digests. The certificates used to generate these signatures must either be 
preshared or utilize a preshared CA and must have a key size of at least 1024 bits (128 bits for 
elliptic curve prime moduli). 

7. (S//NF) Authentication and Integrity FIMACs may be one and the same if FIMAC is chosen for both. 

8. (S//NF) Confidentiality must be provided by AES, Serpent, Twofish, Blowfish, 3DES, or RC4 with a 
minimum key size of 128 bits. Block ciphers must be operated in Galois/Counter Mode (GCM), 
Counter Mode (CTR), or Cipher Block Chaining Mode (CBC). If RC4 is used, at least the first 1024 
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bytes of the cryptostream must be discarded and may not be used.™ AES is recommended due to 
hardware implementations by major CPU vendors and to enable transition to a more secure suite. 

9. (TS//SI) Further than stated above, if RC4 is used the first 3072 bytes of the cryptostream must be 
discarded and may not be used. 

6 (C//NF) The Collection Encryption Suite 

(S//NF) The Collection Encryption Suite is intended to safeguard collected information as it 
resides temporarily on an untrusted file system or as it transits a file-oriented communication 
mechanism (e.g., gap jumpers, bit torrent, HTTP post, etc.). This suite is primarily intended for 
Automated Implants, Autonomous Implants, and collection tools but may be applied by other tools 
utilizing file-oriented transports. Note that the Collection Encryption Suite is intended for files generated 
by a tool for transfer to server and for tasking from server to target, for encryption of data referenced 
repeatedly by a tool utilize the Tool State Encryption Suite. Like the Long-lived Suite this also resembles 
TLS 1.2 except that the Collection Encryption Suite protects a communication in time rather than an 
interactive communication. 

1. (S//NF) Authentication and Integrity must be provided by a signed message digest. The message 
digest must be calculated over the encrypted file. The results of the calculated message digest must 
then be signed using the sender's preshared asymmetric private key and attached to the encrypted 
blob (e.g., appended, prepended, etc). 

2. (S//NF) Confidentiality must be provided by AES with a key size of at least 256 bits. The cipher must 
be operated in Galois/Counter Mode (GCM), Counter Mode (CTR), or Cipher Block Chaining Mode 
(CBC). 

3. (S//NF) For each transmission the encrypting session key shall be generated randomly by the sender 
and used to encrypt the file. The session key shall then be encrypted to the recipient's preshared 
asymmetric public key and attached to the encrypted blob (e.g., appended, prepended, etc). 

4. (S//NF) All asymmetric keys used in this suite must have a length of at least 2048 bits (256 bits for 
elliptic curve prime moduli).™ 1 
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7 (C//NF) The Tool State Encryption Suite 

(S//NF) The Tool State Encryption Suite is intended to safeguard tool components, state, and 
working data that is unsuited for or not ready to be transferred to the server as it resides on an 
untrusted file system or other persistent storage. 

1. (S//NF) Integrity must be provided by FIMAC with a key size of at least 256 bits. 

2. (S//NF) Confidentiality must be provided by AES with a key size of at least 256 bits. The cipher must 
be operated in Galois/Counter Mode (GCM), Counter Mode (CTR), or Cipher Block Chaining Mode 
(CBC). 

3. (S//NF) Optionally a tool may verify a digital signature on a message digest calculated over the 
encrypted form of the relevant state. The signing private key for this purpose must only exist on a 
CIA classified network and must have a length of at least 2048 bits (256 bits for elliptic curve prime 
moduli) while the relevant public key shall be stored on the target. Consequently this additional 
authentication can only verify certain static or default components or states. 

4. (S//NF) There is additional risk to the stored data because of the need for the target component of 
the tool to decrypt the stored state. Consequently tool authors should carefully consider key 
management on the target, this must include any authentication and integrity keys in addition to 
the encryption key. xxl " 
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8 (U) Commentary 


1 (S//NF) In particular, asymmetric cryptography is heavily use to limit the utility of previously captured 
network transmissions by preventing decryption even after reverse engineering the implant and to 
minimize the data encrypted with any particular key material to limit SIGINT cryptanalysis. 

" (S//NF) In particular, the justification that an attacker might hook the OS provided cryptographic API to 
perform reverse engineering of the implant is not acceptable; any service (including execution) provided 
by the OS may be subverted and the security of a proven library outweighs the risk of attack. 

(U//FOUO) A special note for tools targeting versions of Microsoft Windows prior to Vista: the Microsoft 
CryptoAPI (as distinct from the Microsoft CryptoAPI-NG) does not offer all the cryptographic primitives 
required by this document. Specifically the Microsoft Enhanced Cryptographic Provider does not provide 
the message digest algorithms required in 7. These algorithms were added in the Microsoft Enhanced 
RSA and AES Cryptographic Provider (Prototype) bundled with Windows XP SP3. This module, renamed 
Microsoft AES Cryptographic Provider, is also available as an optional hotfix for Windows 2003. Tools 
which must support Windows 2003 or Windows XP SP2 and below should statically link an 
implementation of the necessary primitives from OpenSSL or similar library but may implement these 
primitives. 

(U) Insecure sources of entropy can lead to unacceptably poor quality cryptographic keys and 
therefore total cryptosystem compromise. 

NIST Special Publication 800-90: Recommendation for Random Number Generation Using Deterministic 
Random Bit Generators (Revised March 2007). http://csrc.nist.gov/publications/nistpubs/800-90/SP80Q- 
90revised March2007.pdf 

IV (U) The use of SFIA-1 has been deprecated for digital signature purposes after December 31, 2010. 
Though other uses remain acceptable we have chosen to eliminate its use entirely in the interests of 
simplicity of implementation by not introducing multiple hash mechanisms within a project and for ease 
of assuring the desired security level. 

NIST Special Publication 800-131A: Transitions: Recommendation for Transitioning the Use of 
Cryptographic Algorithms and Key Lengths (January 2011). 
http://csrc.nist.gov/publications/nistpubs/800-131A/sp80Q-131A.pdf 

v (U//FOUO) The digest is calculated over the ciphertext vice plaintext in order to protect against a 
SIGINT actor with access to a compromised host obtaining any information about the transfer. Using the 
example of an exfiltrated file (and depending on communication protocols) it is possible that a SIGINT 
actor could compare the hash value of every file on the compromised host to the intercepted message 
and thereby determine which file was exfiltrated. Calculating the digest over the ciphertext eliminates 
this possible information leakage without altering difficulty of implementation. See also the various 
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debates about Encrypt-and-MAC, MAC-then-Encrypt, and Encrypt-then-MAC. The IV is authenticated by 
the digest in order to prevent a manipulated IV from flipping bits in the first block of the plaintext upon 
decryption under certain modes. 

Vl (U) Asymmetric cryptography is significantly more computationally expensive than symmetric. 
Additionally, limiting the use of asymmetric keys in this way also reduces the amount of data encrypted 
with any given key and consequently makes cryptanalysis much more difficult. 

Menezes, van Oorschot, and Vanstone. Handbook of Applied Cryptography (August 2001). Chapter 12. 

v " (U) Independent generation of keys provides the maximum protection from related key attacks and 
implementation errors. It is, however, more difficult to implement and more wasteful of entropy and 
require more network messages than the use of a KDF. 

NIST Special Publication 800-108: Recommendation for Key Derivation Using Pseudorandom Functions 
(Revised October 2009) 

http://csrc.nist.gov/publications/nistpubs/800-108/sp80Q-108.pdf 

Vl " (U) This maximizes entropy in the derived keys. 

NIST Special Publication 800-108: Recommendation for Key Derivation Using Pseudorandom Functions 
(Revised October 2009) Section 7.3. 

http://csrc.nist.gov/publications/nistpubs/800-108/sp80Q-108.pdf 

lx (U) Compression reduces the amount of information to be encrypted, thereby decreasing the amount 
of material available for cryptanalysis. Additionally, compression is designed to eliminate redundancies 
in the message, further complicating cryptanalysis. 

x (U) Domain specific compression is utilized to maximize compression ratio. 

Xl (S//NF) OS provided compression routines are recommended to ensure correctness without an 
increase in code size. 

x " (U) As a property of the way these cryptographic algorithms are implemented an adversary can XOR 
two ciphertexts encrypted with the same key in order to obtain the XOR of the two plaintexts, thereby 
destroying most or all confidentiality. 

Xl " (S//NF) The exact nature of which algorithms are weak at this stage is highly classified. In the absence 
of those facts this guidance is still relevant; the utility inherent in re-keying derives from minimizing key 
exposure when performing bulk encryption of large amounts of data. Even the most data-intensive NOD 
operations involve several fewer orders of magnitude of data per session key. Consequently, re-keying 
introduces unnecessary complexity (and therefore opportunities for bugs or other unexpected behavior) 
without delivering value in return. 

XIV (U) This avoids a number of attacks inherent in CBC. The key property to these attacks is that the IV be 
unpredictable and, in the interests of not exhausting the target's entropy pool we permit pseudorandom 
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generation of this value. 

Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures. 2004-05-20. 
http://www.openssl.org/~bodo/tls-cbc.txt 

xv (S//NF) The additional entropy from the tag prefix is used as a simple to implement mechanism to 
make IV/session key collisions even rarer than^/ 2 2 56 - Though selecting an initial counter value 
randomly also increases the odds of a collision it also introduces difficulties in exchanging initial value 
and determining whether a counter sequence under the same key will overlap with a different counter 
sequence. 

XVI (U) This substantially increases the difficulty of pre-computing the IV, thereby protecting against 
certain chosen plaintext attacks. 

xv " (U) Reusing IVs under the same encryption key significantly reduces, and for some modes destroys, 
confidentiality. 

XVI " (U) These techniques are simple to implement and ensure no confusion about padding values versus 
message values. 

XIX (U) Bleichenbacher, Chosen Ciphertext Attacks against Protocols Based on the RSA Encryption 
Standard PKCSffl, 1998 

Bleichenbacher, Kaliski, and Staddon, Recent results on PKCSffl: RSA Encryption Standard, 1998. 

xx (S//NF) To reiterate using an example: An implant named X communicates using files sent over FITTPS 
GETs and POSTs. To be compliant with this document, X must ensure that the files transferred are 
compliant with the Collection Encryption Suite and the SSL handshake conducted with the listening post 
is conducted as defined in the HTTPS standard and authenticated against a standard set of root CAs. 

(S//NF) The SSL tunnel X is using to communicate with server might be subject to an SSL MitM attack, 
potentially using a CA issued "valid" certificate. Because X utilized the Collection Encryption Suite the 
take would not be compromised however this sort of interception would permit an adversary greater 
insight into CIA clandestine operations and facilitate more detailed traffic analysis as well as serve as a 
possible avenue of denial of service whereby X believes it has correctly communicated with server and 
therefore might not engage appropriate fallback behavior (e.g., uninstall, change beacon domain, etc.). 
To provide greater security against such an attack, X may go further than required and implement an 
inner cryptostream within the SSL tunnel transfer compliant with the Long-lived Suite. In this way X can 
ensure that it is delivering the raw intelligence only to a server component despite the presence of an 
active attacker. This makes tool X very valuable in those countries known to routinely MitM SSL (e.g., 
China, Iran, and other hard targets). 

XXI (U) RC4 has key scheduling flaws which can reveal the secret key under certain circumstances. This 
countermeasure makes most of those circumstances much more difficult. 
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Fluhrer, Mantin, and Shamir. Weaknesses in the Key Scheduling Algorithm of RC4. Proceedings of the 4 th 
Annual Workshop on Selected Areas of Cryptography, 2001. 

xx " (S//NF) Note that there are two key pairs for a total of four asymmetric keys utilized in this Suite: 
Server Pub | ic (utilized and stored on the target), Server Private (utilized and stored only on classified CIA 
networks), Target Pu bii C (utilized by server, no copy needed on the target), and Target Priva te (utilized and 
stored on the target) 

XXI " (S//NF) One novel technique seen in the wild and provided purely as an example of a clever solution 
is the Random Decryption Algorithm (RDA) technique whereby a piece of malware does not possess the 
decryption key for its own main execution component. This malware is designed to brute force the 
decryption key, a process that can take several hours on modern hardware and has the added benefit of 
extreme resiliency to polymorphic detection heuristics and static scanning. Authors who believe they 
have a particularly novel approach are encouraged to contact the OCRB for a detailed discussion. 
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